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ABSTRACT 

The Goddard Space Flight Center’s new thermal vacuum data acquisition system 
is a networked client-sever application that enables lab operations crews to monitor all 
tests from a central location. The GSFC thermal vacuum lab consists of eleven chambers 
in Building 7 and one chamber in Building 10. The new data system was implemented 
for several reasons. These included the need for centralized data collection, more flexible 
and easier to use operator interface, greater data accessibility, a reduction in testing time 
and cost, and increased payload and personnel safety. Additionally, a new data system 
was needed for year-2000 compliance. 

This paper discusses the incorporation of the Thermal Vacuum Data System 
(TVDS) within the thermal vacuum lab at GSFC, its features and capabilities and lessons 
learned in its implementation. Additional topics include off-center (Internet) capability 
for remote monitoring and the role of TVDS in the efforts to automate thermal vacuum 
chamber operations. 


INTRODUCTION 

The Space Simulation Test Engineering Section at GSFC provides twelve test 
facilities that range in size from 2’x2’ to 27’x40’ and are spread out across two buildings. 
Nine thermal/vacuum chambers and two temperature/humidity chambers are located in 
Building 7. One vertical thermal/vacuum chamber is located in Building 10. All 
chambers can operate on a 24-hour per day schedule with three shifts of operations crews 
overseeing command and control for each chamber and its associated test. Because of 
the volume of testing and the large layout of the laboratory chambers and control 
systems, it is necessary to have a central point of data acquisition and test monitoring. 

The previous data acquisition system was a proprietary network of terminals and 
scanning modules running HP-BASIC. The facility and payload data were scanned by 
separate modules. A typical chamber monitoring setup would include one monitor for 
tabular data displays and one monitor for graphical data display. Locally connected 
printers provided hard copies of data. 


The goal of TVDS was to create a centralized, flexible, user-friendly and up to 
date system using off the shelf software. Required features included the following 

1 . Integrate facility and payload data into a single data source 

2. Provide secure dependable data storage 

3. System must communicate over a secure, private local area network (LAN) 

4. Each client workstation must be fully customizable in terms of data display 

5. System must be flexible enough to integrate with automation SC AD A systems as 
well as be able to adapt to future needs of the lab 

6. All data must be archived and readily available for user requests 

Additional requirements included sensor alarming, networked printing, and the ability to 
connect to TVDS remotely. 


DESCRIPTION 

The new thermal vacuum data system (TVDS) was developed on an Oracle 
database using PowerBuilder for the graphical user interface. These two systems are 
bridged together with a custom C++ SCADA application, which acquires test data from 
an array of Hewlett-Packard 3852A and VXI data acquisition units. The TVDS 
application runs on an isolated TCP/IP network and utilizes a dedicated Digital Alpha 
server that allows for quick and efficient database transactions. Figure 1 shows the basic 
layout of the system. The network resides completely within buildings 7 and 10 and is 
isolated from the GSFC network. The advantage to this is limited traffic and superior 
speed and security. 



Figure 1 Overview of Thermal Vacuum Data System 


Database Server 

The database server is the central repository of data acquired throughout lab 
testing. The database engine, Oracle Server was chosen for its flexibility, robustness and 
multi-platform packaging. Third party software and applications can easily integrate into 
an Oracle database. This allows for a wide range of solutions and possibilities as the data 
system continues to grow. Software already integrated includes PowerBuilder, 

Intellution, FactoryLink and custom SCADA C++ and Visual Basic applications. 

The Oracle server runs twenty-four hours a day on a UNIX platform. The 
computer is a Digital Alpha Server 2100 5/300 with 256 MB RAM and 1 8 GB hard drive 
space. This server uses a RAID 5 setup. All data is routed to and from the database 
through Cisco Fast Ethernet switch. 


Database Structure 

The Oracle database is structured into a series of tables based on each chamber. 
This was done for two reasons. By limiting tables to hold data specific to a facility, the 
size of the tables may be smaller and easier to maintain, and it allows for a faster retrieval 
of data. Because of the large volumes of data that are involved in thermal vacuum 
testing, the speed of data retrieval is very important. 






Each chamber has a table devoted for measured test data, a directory of chamber 
and payload sensors, alarm limits associated with each sensor, and a list of sensors in use 
(active). Within each chamber’s subset of tables, specific test data is referenced by a 
unique test number. This test number is the primary key that identifies all test 
parameters, recorded data, alarm limits, and user display configurations. 


TVDS Network 

TVDS makes use of two network systems: TCP/IP local area network (LAN) and 
Modbus+. Figure 2 shows how communication with the Oracle server is possible. 
SCADA and TVDS use TCP/IP protocol for all data transmissions, including SQL*Net 
transmissions from the SCADA to server and TVDS client-to-server communications. 
Because the LAN is only accessed by clients using TVDS, network traffic is minimal. 
This is important because data requests from the TVDS application can often produce 
large data sets. Historical data display showing data of 8 to 24 hours may take 1 to 2 
seconds for retrieval. The number of connections to the system ranges from 6 to 20 
connections with each instance updating every two minutes. 

Using the TCP/IP protocol, it is also possible to access TVDS through and 
Internet browser. As shown in the bottom of Figure 2, a link from the Goddard Code 549 
website gives access to an application server. This server runs multiple instances of 
TVDS and redirects their displays to remote connections. This will be discussed in detail 
in this paper. 

The Modicon Modbus+ network is a token ring style system that is used by the 
programmable logic controllers (PLC) in buildings 7 and 10. PLCs that control valves, 
motors and pumps can also scan chamber sensors. Automated chambers use SCADA 
machines to monitor and control these systems. These SCADAs are setup to 
communicate on both the Modbus+ network using SA-85 network cards as well as the 
TVDS Ethernet LAN using standard 3Com 10/1 00Mb adapters. 



Data Acquisition 

Data is acquired by the Supervisory Control and Data Acquisition (SCAD A) 
computers every two minutes and recorded in the Oracle database. Two SCAD As are 
utilized within the lab for facility and payload data, one for building 7 and one for 
building 10. Each machine is time synchronized with the database server. The SC AD A 
applications are custom C++ or Visual Basic programs that establish and maintain 
communication with the acquisition hardware and Oracle database. After each data 
acquisition cycle, temperature averages and gradients are calculated and written to the 
database with other measured data. In addition, each measured sensor is compared to its 
sensor limits. Any sensor breeching a limit (high and low temperature, rate) is displayed 
in an alarm window on each client station. 

Several types of sensors are used during testing including thermocouples, 
thermistors, silicon diodes, ionization gauges, and capacitance manometers. Four types of 
data acquisition units are utilized during testing: HP3852, VXI, M2000 and Modicon 
PLC. 



HP3852 


The Hewlett-Packard 3852 Data Acquisition System (DAS) is the primary 
acquisition unit for the lab. All facility and payload thermocouples are scanned at two- 
minute intervals by an array of HP3852. These units are the same as those used for the 
previous data system. Because some chambers have a small number of sensors (<50), 
their scanning is shared with other chambers on a single HP3852 unit. Larger chambers 
(225, 290) with large sensor libraries require dedicated units. Communication with the 
network is via the IEEE-488 bus and HP LAN 2050A gateway. 


VXI Main Frame 

Chamber 290 uses a Hewlett-Packard E8401A VXI Main Frame for acquisition of 
all payload sensors. Seven high-density C-size E1476A multiplexers are capable of 
reading up to 64 channels each which is sufficient to scan all of the chamber’s payload 
sensors. The VXI chassis was installed as part of an effort to upgrade and standardize the 
data acquisition hardware. The HP3852A units, which are now obsolete, will be phased 
out and replaced with VXI units. VXI data acquisition offers a system-level standard 
design that can support a variety of hardware manufacturers, provides high transfer 
speeds, and plug and play flexibility. 


QCM M2000 

The QCM Research Model 2000 Control Data/Acquisition Unit is used for 
gathering all thermoelectric quartz crystal microbalance (TQCM) data. This unit is used 
for outgas measurement and contamination detection during testing. The M2000 
communicates with the SCADA over an RS-232 link. The acquisition interface, which 
runs on the building 7 SCADA was developed using FactoryLink and can control up to 
12 devices at once. The FactoryLink application writes all active QCM frequency, 
temperature and voltage measurements to the database at two-minute intervals. An 
example of this data is shown in Figure 3. 


Modicon 984 PLC 

Several of the lab chambers (225, 281, 290) make use of programmable logic 
controllers (PLC) for temperature and pressure measurement as well as valve, motor, and 
pump control. Through SCAD As, selected sensors can be written to the Oracle database. 
The link from Modbus+ to the TVDS LAN is established through Visual Basic scripting 
in the SCADA applications. 


Client Stations 


Client station machines are desktop computers with a CPU speed ranging from 
300 to 500 MHz and RAM ranging from 64 to 128 MB. Network communication is 
through a 10/ 100MB Ethernet network adapter. The TVDS application files require 
approximately 2 MB of space. Additional software requirements include Oracle Client 8, 
any FTP utility and a time synchronization utility. The recommended monitor display 
setting is 1280x1024. 

Each client station runs TVDS, the graphical user interface (GUI) or Human 
Machine Interface (HMI) that is used to display and monitor all tests within the lab. 

TVDS was developed using PowerBuilder from Sybase. The use of PowerBuilder for 
the human machine interface allows for a powerful Windows based client/server 
application that connects to the Oracle Database Management System (DBMS). 
PowerBuilder applications are developed using PowerScript, an object oriented 
programming language that lets the developer dynamically control objects throughout the 
application. Techniques such as encapsulation, polymorphism and inheritance, which 
object oriented programming provides, allows for efficient, powerful and reusable code. 
The interface is run from an executable file residing on each client computer. By 
running the application from each client, the server can be used exclusively for writing 
and retrieving data. 

The interface is designed so that each chamber may be monitored from any 
computer at any time. Each computer independently retrieves data from the database 
tables. This allows for unique custom display editing of the same test for every computer 

The presentation of data within the application can be customized both before and 
during the test without interrupting incoming data or other computer displays. Options 
available to the operator include activating or deactivating sensors or tags, setting alarms 
for any tag, configuring and monitoring multiple TQCM devices, create and edit averages 
and gradients dynamically, access to tag libraries and printouts of all relevant data and 
test information. Data can also be saved and exported to a variety of file types including 
text, Microsoft Excel and Data Interchange format. 

Data can be presented in two formats: tabular and graphical. Both formats can 
present current test as well as historical data. Figure 3 shows both tabular and graphical 
display of TQCM data. The left side shows historical data, and calculations. The two 
plots on the right side show one hour of temperature and frequency data. 

By allowing the operator to customize each screen through simple screen editors, 
relevant data can be grouped together in any fashion so that tests can be monitored safely. 
The tabular data format displays measured test data on tab pages in columns. Each tab 
page can display up to 160 tags and an unlimited number of tab pages can be defined for 
each chamber. Data displayed in graphical or plot form is useful for monitoring trends 
during a test. Up to eight tags can be displayed on each plot and an unlimited number of 
plots can be defined for each chamber. 
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Figure 3 Tabular and Graphical display of TQCM data 


TVDS FEATURES 

Several features exist within TVDS that make it useful to both test operation 
crews as well as test projects. These features include near real-time monitoring, 
customized displays, shared displays, constant alarm monitoring, alarm limit editing, and 
remote connections. 


Monitoring 

Each client running TVDS automatically updates any windows showing measured 
data. Updates occur every two minutes on the odd minute. The SCADA machines update 
the database every two minutes on the even minute. Therefore, there is a one-minute lag 
between the data acquisition and data refresh. Because of the volume of data recorded 
and the necessary calculations and limit checks, it is necessary to ensure that the SCADA 
application has been given sufficient time to insert and update the appropriate database 
tables. In addition to updating data displays, any alarms associated with the monitored 
tests will display as well. 



Alarm Limit Monitoring and Editing 

As each sensor is collected by the SCADA, its value and rate of change is 
compared to its stored limits. Tables of limits for each chamber are configured at the 
beginning of a test. These limits can also be modified at any point during the test through 
an alarm limit editor. Font colors are used to display sensors that are under alarm. Red 
and yellow are used for temperature limits and blue for rate limits. 

When the SCADA determines that a sensor has passed a limit, its value, limit and 
scantime are entered into an alarm table. For each test enabled on a client machine, 

TVDS checks the alarm table for each chamber. Any entries for that scantime are 
immediately posted in a small window, as shown in Figure 4. An audible alarm is also 
available and sounds for each update that has an alarm. The alarm window will remain on 
top of all other open windows and displays each entry in a color specific to its type of 
alarm: yellow or red for If the tabular display or summary page is displaying the sensor(s) 
under alarm, they will be shown in the alarm color as well. Note that in Figure 4 there 
are two sensors in blue in the first column as well as one sensor in the second column. 


Customized and Shared Displays 

An important requirement of TVDS was to allow each client to create and modify 
all tabular and graphical screens as needed. This is accomplished through a series of 
screen editors that can be used at any time during a test. For any chamber that is under 
test, a client can create two types of displays: tabular or graphical. As shown in Figure 4 
tabular displays show data in four columns per tab. Within each column, the sensor or 
tagname is given along with its current value and location in the chamber. The user has 
full control over the layout of tags on each tab and may add or delete tabs as needed. 
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Figure 4 TVDS Tabular Display 


The second method of displaying data in TVDS is graphical. Each plot can 
display up to twenty-four hours for eight sensors. In Figure 5, fours hours of data is 
shown for three payload sensors in Chamber 239. At the bottom of each plot, the legend 
displays the sensor name and its location within the chamber. Properties on this plot that 
are configurable by the user include the scale of the time and value axis, the amount of 
data retrieved, autoscale, auto scroll, plot title, background color, tab title and plot resize. 
Plots can also automatically adjust line types for black and white printing. As with the 
tabular displays, there is no limit to the number of plots the user can create. 


Displays can also be shared or copied from other client stations. This allows 
projects to set up one station and quickly copy the displays over to other machines. This 
can be done when a display is first created or at any point during the test. 





Figure 5 TVDS Graphical Display 


Remote Connections 

During a test, projects often require the use of several data stations. Projects 
members and engineers often request to have access to TVDS from their own computers. 
The data system operates on a private network in building 7 and 10. The obvious 
limitation to this is that computers on other networks cannot access test data. An 
additional limitation to this client-server network is that each client must have Oracle 
Client installed. Therefore, each client outside of the TVDS network must have access to 
the software as well as a license run it. 

In order to provide computers outside of the TVDS network with access to the 
TVDS application, an application server was implemented using Sybase’s Web 
Development Kit. As shown in the bottom of Figure 2, remote clients connect to the 
application server through an Internet browser. For the initial rim, the client downloads a 
small executable that allows it to communicate with the application server. The 
application server then establishes a secure communication path, starts an instance of 
TVDS and redirects the graphics to the client. By running each instance of TVDS on the 
application server, data transmission remains within the TVDS network and only 
graphical images are transmitted to the user. In this way, the remote client can run the 





application without any loss in program functionality and without any TVDS application 
files or Oracle software or licensing. 


TVDS AND AUTOMATION 

The automation of test chambers within the lab requires the design and 
implementation of computer interfaces that permit monitoring and command control. 
TVDS is designed to easily work with automation interfaces. The primary role of the data 
system in chamber automation is saving important data scanned by automated processes. 
This task is performed on a chamber’s SC ADA machine and runs as a background 
process. Integrating the data system into automation projects provides seamless 
transmission of data. TVDS is able to utilize this and display any data that a SCADA 
system can record. 


ACHIEVEMENTS, PROGESS AND ISSUES 

The new data system was brought online in November 1998, and by January 
1 999, the new system was recording data for all the lab chambers. By the summer of 
1999, TVDS was integrated into the Chamber 290 automation project. This SCADA is 
responsible for acquiring all of the chamber thermocouple data. Additional projects that 
required the use of TVDS include a new remotely operated heater rack system that was 
brought online in March 2000, and a simulation/prediction model used for projecting 
thermocouple temperatures during a test. The new data system has recorded over 500 
tests and over 67,000 hours of test data through July 2000. 

The TVDS application has undergone several minor modifications since it was 
brought online. While some of these modifications involved code debugging or database 
table changes, the system has had no significant down time or failures. Feedback from 
the project members and operations crews has provided useful information regarding 
changes or improvements and future releases. 

The thermal vacuum lab is a 24-hour, 365 days a year facility, therefore, the data 
system must run continuously. Because of this constant influx of data, large amounts 
physical storage space is needed. As in any networked database system, every effort 
must be made to maintain reasonable table space. Storage space is the primary issue for 
the new data system. Some tests may use several hundred sensors in a chamber that may 
run for several weeks. The measured data, along with any recorded alarms may require 
several hundred megabytes of space. To maintain safe levels of free disk space, the data 
of completed tests are backed up to tape and CD-ROM and removed from the server. 

The completed test data is available for requests in ASCII format. The complete test and 
all database tables are also backed up in a compressed Oracle export file. 



FUTURE GOALS 


TVDS will continue to grow and change as lab needs dictate. As part of the 
original design, TVDS is flexible enough to integrate with other applications and 
communicate with other systems and networks. The automation project of chamber 238 
began in March 2000 and will require data logging with the new data system. This will 
require an Intellution based SCADA system similar to that of chamber 290 mentioned 
above that scans and writes facility data to the database. 

Another goal of the data system involves the standardization of data acquisition 
hardware. With the rise of VXI as an industry standard and a variety of manufacturers 
that support VXI data acquisition, it is a logical choice for replacing the HP3852 units 
used throughout the lab. This step towards standardization within the lab has started with 
chamber 290 as mentioned earlier. 

A third goal of the new data system will be to investigate and possibly incorporate 
fiber optic networking into the lab. While sections of the Modbus+ network already uses 
fiber optic, the standard twisted-pair Ethernet LAN cabling is vulnerable to electrical 
interference, which can often present cable routing challenges within the lab. Fiber optic 
cable would eliminate the issue of networking in an electrically hostile environment. In 
addition, because fiber optic is capable of carrying large volumes of several types of data, 
it may be possible to combine the data transmissions of Modbus+ and TVDS into one 
fiber optic system. 

Additional goals of the thermal vacuum data system include modifications to 
TVDS that allow for quick setup of tests. This would include an automated process of 
updating database tables relating to sensor descriptions and alarm limit configurations. 
The post-test distribution of data based on user request is another feature that will be 
automated. 


CONCLUSIONS 

The upgrade of the thermal vacuum data system for Space Simulation Test 
engineering lab at GSFC has produced a flexible, robust and dependable system that can 
provide and array of test monitoring and support capabilities. By establishing a 
centralized acquisition system, projects and operation crews can realize an increase in 
data accessibility, as well as an overall reduction in testing costs and payload and 
personnel safety. With over 67,000 hours of test monitoring completed in less than two 
years, the data system has established itself as a reliable tool of GSFC’s thermal vacuum 
testing process. 


